The Push Notifications Console now includes metrics for notifications sent in production through the Apple Push Notification service (APNs). With the console’s intuitive interface, you’ll get an aggregated view of delivery statuses and insights into various statistics for notifications, including a detailed breakdown based on push type and priority. Introduced at WWDC23, the Push Notifications Console makes it easy to send test notifications to Apple devices through APNs. Learn more.

Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello, We develop Barra, an order-ahead pickup app in Saudi Arabia built to support productive families: small home-based businesses, mostly women cooking or making handmade products from home. Customers order from them in our app and collect the order from their car. The families depend on one notification: when a customer places an order, the family's iPhone receives a "New order" push with our own sound. They have a few minutes to accept it before it is cancelled automatically, so hearing that sound is how they earn their income. The problem: families report that this notification sometimes plays its sound and sometimes arrives silently — same iPhone, same settings, ring/silent switch off. Our server logs show every push is sent and accepted by APNs (via Firebase Cloud Messaging) and the notification itself appears. Only the sound is sometimes missing. We are not trying to bypass the silent switch and we are not asking for Critical Alerts. If a family puts the phone on silent, we respect that. The sound only goes to merchant devices, only for a real customer order (plus at most one reminder per minute while the order is still waiting). Our setup Headers: apns-push-type: alert, apns-priority: 10, an apns-collapse-id per order aps: alert {title, body}, sound: "bra_order_alert.caf", badge: 1, interruption-level: "time-sensitive" bra_order_alert.caf: IMA4, 44.1 kHz, 16.4 s, in the main bundle Foreground: willPresent returns banner + badge + sound Our next build adds the Time Sensitive Notifications entitlement (it was missing before) iPhones on iOS 18.x, 26.x and 27.0 Questions Which conditions can make iOS deliver an alert push silently while the silent switch is off? For example notification summary, Focus, several notifications close together, Apple Watch or Bluetooth audio routing, replacing a notification with the same apns-collapse-id, the sound file's length or format, or the app's own audio session. Is there anything in our payload or sound file that could make the sound play only some of the time? When a notification replaces an earlier one with the same apns-collapse-id, does iOS play the sound again? What do you recommend for merchant apps so order notifications are reliably audible, while fully respecting the silent switch? Filed as FB25199572. Thank you!

I have so far been unable to enrol a macOS 27 beta VM in to Jamf since initial beta release. Is this by design? I can’t find any documentation or posts on apple developer forums about this anywhere. My agentic coding session has done some probing around in the VM and it thinks something is going wrong with Secure Keychain within the VM. Everybody on my team is observing the same behaviour as this, and I’ve had it happening across two different laptops (one of them which is, itself, running the latest macOS 27 Beta, and the other which I created a Beta VM by installing Tahoe in the VM, logging in to iCloud, and enabling Beta channel updates) The only thing we’ve found we can do so far is to join to Jamf in Tahoe first, but the problem I have there is, often times the option for Beta channel updates just doesn’t present itself in System Settings -> Software Update after signing in to iCloud, and I don’t know why it sometimes does but often doesn’t. Logs from agentic coding session below: The core log evidence This is the whole causal chain, from the 27 guest's unified log, inside 370 microseconds. Innermost failure first: 05:24:04.967316 apsd: (CryptoTokenKit) [com.apple.CryptoTokenKit:sepkey] <sepk:* kid=0000000000000000>: (apsd) unable to generate key: error e00002e2(-536870174) ACL=<SecAccessControlRef: dk;ock(true);odel(true);osgn(true);oa(true);okd(true)> 05:24:04.967433 apsd: (Security) [com.apple.security:seckey] SecKeyCreateRandomKey_ios failed: NSOSStatusErrorDomain Code=-25308 "Failed to generate keypair" (errSecInteractionNotAllowed / Interaction is not allowed with the Security Server.) 05:24:04.967574 apsd: (DeviceIdentity) com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967600 apsd: [com.apple.apsd:courier] APSBAAClientIdentityProvider failed to obtain a BAA cert, error: com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967686 apsd: [com.apple.apsd:courier] <APSCourierConnectionManager; production>: Stream error occurred for : APSErrorDomain Code=1 "Told not to connect after fetching server bag: (null) - closing stream" Read bottom-up: Secure Enclave key generation fails, so MobileActivation cannot create the reference key, so apsd cannot obtain its BAA device-identity certificate, so APNs tells it not to connect. kid=0000000000000000 means there is no key id at all. Then every courier line reports Connected on 0 interfaces, and mdmclient sets its PushWakeTopics only to get Connection Invalid for service com.apple.apsd and tear down. The command to regenerate it: log show --predicate 'process == "apsd"' --last 60m --info | grep -iE 'BAA|unable to generate key|server bag'. New control, collected just now mac26 happened to be running, so I got the comparison. macOS 26.6 (25G72) guest, same host, same network, 3 days uptime: BAA_FAILURES: 0 SEPKEY_FAILURES: 0 APNS_SOCKETS: 192.168.64.8.52286 -> 17.57.146.7.443 ESTABLISHED 192.168.64.8.52285 -> 17.253.77.203.443 ESTABLISHED (+ 3 more into 17.0.0.0/8) No BAA or courier complaints at all over 6 hours, and live connections into Apple's network. So a virtualised guest per se is fine; the 27 guest specifically cannot mint the key. The physical host, also on macOS 27.0, likewise logged zero of both failures over 3 hours.

Hello, We are investigating intermittent push notification delivery issues for a production iOS application. Our push architecture is: Application backend → Firebase Cloud Messaging (FCM HTTP v1) → APNs → iOS devices During a recent large-volume notification event, some iOS users reported not receiving the notification, while many other users successfully received the same type of notification during the same period. From our sending platform: The affected notification requests were successfully accepted by FCM. No sending error was returned for the affected cases. The FCM registration tokens of the affected users were verified and were not invalid or unregistered. We then reviewed the production metrics in Apple Push Notifications Console. For a recent one-week period, the console reported approximately: Received by APNs: 729.7K Delivered to Device: 553.5K Delivered to Device (From Storage): 125.2K Stored - Device Offline: 58.4K Stored - Power Considerations: 5.7K We understand that these status counts represent status occurrences and are not necessarily mutually exclusive. For example, the same notification may first be stored and later delivered from storage. However, we would like to better understand the relatively large number of notifications being stored by APNs. Could Apple please clarify: What device or APNs conditions specifically cause a notification to be classified as Stored - Device Offline? What conditions cause Stored - Power Considerations for normal user-visible alert notifications? For an application with a large production user base, are these volumes or proportions considered normal APNs behavior? When a notification is stored because the device is offline or because of power considerations, under what circumstances can it eventually fail to reach the device? If multiple notifications for the same application/device arrive while the device is unavailable, can an earlier stored notification be replaced or discarded by a newer notification? Because our APNs provider connection is handled by FCM, we do not currently have the APNs ID for each individual request. Is there another Apple-supported way to investigate an individual production notification, or correlate it with the Push Notifications Console delivery data? Are there any recommended APNs configuration or sending practices that could reduce the number of notifications entering these stored states? We can provide exact UTC timestamps, Push Notifications Console screenshots, exported metrics, and additional production information privately if an Apple engineer needs them. Thank you.

We are considering developing an iPhone application for workers operating in environments where safety is critical and notifications may involve life-threatening situations. We understand that Apple's Critical Alerts feature can deliver notifications with audible alerts even when the device is muted or Focus mode is enabled. However, we would like to know whether it is possible for a third-party app using Critical Alerts to present an emergency alert directly on the screen in the foreground, similar to the way iOS displays government-issued emergency alerts such as Earthquake Early Warnings (EEW). Specifically, can a third-party application trigger a full-screen emergency alert that immediately appears over other applications, rather than relying solely on a notification banner and alert sound? If this is not possible, are there any Apple-supported mechanisms or APIs that allow life-safety applications to provide a comparable user experience for urgent emergency notifications? We would appreciate any clarification regarding the capabilities and limitations of Critical Alerts for life-safety use cases.

I have several Live Activities running concurrently for different trips in a delivery app (same app, multiple active Live Activities, each with its own activity ID). I update relevance-score via ActivityKit push notifications at each status change: Trip picked up → 20 route to destination → 40 Arrived at destination → 60 Delivery delayed → 80 Confirmed → 100 (sent with "event": "end") Per Displaying live data with Live Activities, "the relevanceScore also determines the order of your Live Activities on the Lock Screen." However, when the Confirmed Live Activity is sent with "event": "end" and "relevance-score": 100, it does not move to the top of the Lock Screen stack, even though other still-active trips have lower relevance scores (20–80). Questions: Does relevanceScore only apply to ordering among currently active Live Activities, and get ignored (or treated differently) once a Live Activity has ended? Is there a separate/implicit ordering rule for ended Live Activities during their dismissal window (e.g., always sorted below active ones, or sorted by end time instead of relevanceScore)? Is there a recommended pattern for making a Live Activity appear prominently right as it ends — e.g., sending a high relevanceScore via update first, then a separate end shortly after? This isn't documented explicitly in either the "Configure the Live Activity" or "End the Live Activity" sections, so I wanted to confirm the intended behavior rather than rely on trial and error.

I'm implementing the new NowPlaying framework's remote-session push-to-start flow (per Publishing remote media sessions) to show a Sonos-like remote speaker's playback on the Lock Screen/Control Center without requiring my app to be running. The docs say: Your server can start, update, or end sessions when your app isn't running. Use this approach when playback starts from a remote device without someone opening your app. That section never mentions requestToBecomeSystemPrimary() — that's only documented under "Start and update sessions from your app," with a note that it's a no-op unless the app is foregrounded. In my testing, though, a session created purely via a push-to-start "event":"start" push never shows up anywhere in system UI (not Control Center, not the Lock Screen) until I open the app at least once. The mechanism itself works correctly — RemoteMediaSessionExtension.session(_:) fires reliably, decodes the attributes correctly, and returns a valid RemoteMediaSessionRepresentable (confirmed via on-device logging: no errors, clean construction every time, across dozens of test pushes). It just isn't surfaced. To rule out anything on my end, I've tested: Sending via my own server (correct apns-topic/apns-push-type headers, confirmed working via HTTP/2 200 and correct decode) Sending via the Push Notifications Console directly, with Environment explicitly set to Production (my push-to-start token only validates against production, matching the known dev-signed-token-provisions-against-production quirk) A hand-built, minimal, fully valid payload for a completely fresh, never-before-registered session id Every combination produces a correctly-constructed session that's invisible until the app opens — at which point my own app code (unrelated to the push) independently constructs and promotes its own session via RemoteMediaSession.start() + requestToBecomeSystemPrimary() in the foreground. Has anyone gotten a push-to-start session to actually appear on the Lock Screen/Control Center without opening the app first? Is there an additional step beyond what's in the current docs (some other registration, entitlement, or timing requirement) that's needed for that, or is this expected behavior right now and the docs are ahead of the implementation? FB24876585 filed on Feedback Assistant with app logs attached.

I'm having problem with my VoIP application. My app uses Callkit and VoIP push notification to make SIP calls between same app. Sometimes after taking the phone the call doesn't start. I found out iOS is not sending back audioSession didActive response to my app. Is this known issue or bug?

I had strange experience few days ago. After sending VoIP push notification request properly to APNs it took nearly 10 minutes to actually receive the Push notification. Could this be cause by other than network issues? (i.e. APNs issue or iOS issue)

I am extremely new to this so please bare with me. I am trying to enable push notifications for my app and understand that I need to go to Apple Developer account, go to Certificates, Identifiers & Profiles → Keys and create an Apple Push Notifications service (APNs) auth key. Download the .p8 file and copy its 10-character Key ID (Apple only lets you download it once). In other tutorials it shows that there should be multiple check box selections to choose APN when generating a key but my screen looks like this? Can anyone advise on what I am doing wrong?

I've filed FB24763792 about numeric JSON reserialization and the Live Activity content-state size limit. A compact JSON content-state can be below 4,096 bytes but expand beyond that limit when Foundation parses and reserializes its numbers. Here is an entirely synthetic Foundation reproduction: import Foundation let row = #"{"a":1.91,"b":1.91}"# let rows = Array(repeating: row, count: 100).joined(separator: ",") let input = Data("{"sequence":1,"readings":[(rows)]}".utf8) let object = try JSONSerialization.jsonObject(with: input) let output = try JSONSerialization.data(withJSONObject: object, options: []) print(input.count, output.count) On macOS 26.6.2 and the iOS 26.5 simulator, this prints 2027 4827. Foundation writes 1.91 as 1.9099999999999999. Change both values to 1.95 and it prints 2027 2027. In a separate local ActivityKit test, we passed the Foundation-reserialized data through a Decimal-based Codable state that preserved the expanded byte count: The 1.95 control remained at 2,027 bytes and applied successfully. The 1.91 case expanded to 4,827 bytes and was rejected with "Payload maximum size exceeded." The activity retained its previous state. We also tested the exact boundary: a 4,096-byte encoded dynamic state applied, while 4,097 bytes was rejected. Static attributes did not count toward that tested local-update boundary. This investigation began with remote Live Activities remaining stale while APNs returned HTTP 200 for dispatched updates. The device logged "Error extracing payload from incoming message" (spelling as logged). We are confident numeric expansion is the mechanism behind our issue. The tests above reproduce expansion and rejection locally; they do not replay an exact captured failed remote push. The ContentState documentation specifies a 4KB limit but doesn't make remote JSON normalization clear: https://developer.apple.com/documentation/activitykit/activityattributes/contentstate Questions for Apple: At what stage is remote content-state size measured? Can internal reserialization preserve compact numeric representations, or can the limit use the supplied content-state bytes? Can rejected incoming updates expose the underlying size error and measured byte count? The synthetic reproducer and a simulator diagnostic collected immediately after the local rejection are attached to FB24763792. verified-results.txt control-content-state.json expanding-content-state.json

On a single device, a production-entitlement build of our app calls -[UIApplication registerForRemoteNotifications] and neither delegate callback is ever invoked. Not application:didRegisterForRemoteNotificationsWithDeviceToken:, and not application:didFailToRegisterForRemoteNotificationsWithError:. We wait 10 seconds and get nothing, on every launch, over more than 24 hours. UNAuthorizationStatus is .authorized, verified programmatically at the moment of the call rather than just in Settings, and the installed binary carries aps-environment = production, read off the device. The identical source signed with aps-environment = development receives a token in under one second on that same handset. We have isolated it to one cell of a four-way matrix. Production entitlement on this device: no token, no error, reproducing on both the App Store and TestFlight builds. Development entitlement on this device: token in under one second. Production entitlement on other devices: works, and other users register daily. Production APNs for other apps on this device: works, other App Store apps receive push normally. Already ruled out: notification authorization; the entitlement; delegate wiring (UIApplicationDelegateAdaptor is attached, and that same delegate receives the token when the app is development-signed); delete and reinstall from both the App Store and TestFlight; Reset Network Settings; reboot; airplane-mode cycle; an alternate network. Device context: iPhone 12 Pro (iPhone13,3) on iOS 26.6.1 (23G83). It is an AppleCare replacement unit, restored from a backup of the previous handset. Our working theory is stale per-app push registration state carried across in that restore, since reinstalling does not clear it, which suggests whatever is stuck does not live in the app container. Filed as FB24525199 with a sysdiagnose captured while the APNs logging profile was installed. Two questions. First, is there any way to force a device to discard and re-provision its per-app APNs registration state, short of erasing and setting up as new? Second, is the absence of both callbacks a known state? Every reference I can find treats didFailToRegisterForRemoteNotificationsWithError as the guaranteed path when registration cannot complete, so silence from both leaves an app with no signal to act on and no way to tell the user what is wrong.

The company I work for sends large amount of traffic to APNs on behalf of our customers, with rates up to 50k/second at peek times. While a vast majority of the messages are successful or return a proper error code that we can parse and honor, roughly 1.5 million times per day our connections are being closed without warning. The networking library we use, https://github.com/hyperium/h2, is exposing these as ErrorKind::ConnectionReset or ErrorKind::BrokenPipe. From our reading of the APNs documentation, it is unclear what the correct response is when this occurs. There is no idempotency key included with our messages, so attempting to resend the message again seems frought with the potential for double sends. However, it some cases it seems clear that at least some of the messages in flight over that connection where never sent out at all. We found this open source project unconditionally retrying messages in this case. https://github.com/rpush/rpush/pull/734 Could someone from the APNs team please lay out the expected behavior a client should have when our connection is unexpected closed in this manner?

Mac 应用使用了 共享 App 群组容器 特性，无法从A账号转移到B账号。大家有人碰到这个问题不？求解决。

Hello Apple Developer Technical Support, We observed an unusual increase in APNs 410 Unregistered responses in our production iOS app between July 10 and July 24, 2026: Before July 10: approximately 1,500–5,000/day July 10–24: approximately 15,000–30,000/day, a 5–10x increase After July 24: the volume stabilized and did not continue to increase We found no relevant changes to our client, server, or APNs configuration during this period, and no corresponding increase in 403 ExpiredProviderToken or 400 BadDeviceToken. We also found that the last app-open dates of the affected tokens were broadly distributed from August 2025 to June 2026, with no clear concentration around a specific inactivity period. We are not using 410 Unregistered as an uninstall signal. Our main concern is understanding why the response volume increased so significantly during this specific period. Could Apple confirm: Whether there were any APNs-side changes, maintenance activities, or changes in token processing behavior between July 10 and July 24 that could explain this increase? For a device token that becomes invalid due to app uninstallation, after how many push attempts would APNs typically return a 410 Unregistered response? Is it expected to return 410 on the first push attempt, or only after multiple push attempts?

We are facing an issue with push notifications on our iOS production application and would appreciate guidance. Issue Summary Push notifications were working correctly previously but stopped working around two weeks ago. We use Firebase Cloud Messaging (FCM) for push notifications, which delivers notifications to our iOS application through APNs. The issue appears to be related to existing FCM tokens. Existing FCM Token We have an FCM token already stored in our production backend database. When we try to send a notification using this token: Our backend sometimes receives the following response: { "error": { "code": 404, "message": "NotRegistered", "status": "NOT_FOUND", "details": [ { "@type": "type.googleapis.com/google.firebase.fcm.v1.FcmError", "errorCode": "UNREGISTERED" } ] } } In some cases, the API request appears successful, but the notification is still not received on the iPhone. We also copied the exact same existing token and tested it directly using Firebase Console → Send test message. The notification was not received on the device. Newly Generated / Retrieved FCM Token We then generated/retrieved the FCM token again from the same application and tested it directly from Firebase Console. Using the newly retrieved token: The notification was successfully received on the same iPhone. This means the following behaviour is observed: Existing FCM Token ↓ Backend may return 404 UNREGISTERED OR Firebase may accept the send request ↓ Notification not received But after retrieving the token again: FCM Token Retrieved Again ↓ Firebase Console Test ↓ Notification received successfully Client-Side Configuration We have confirmed the following: APNs device token is successfully generated. FCM registration token is successfully generated. Notification permission is granted. The application is connected to the correct Firebase project. FirebaseAppDelegateProxyEnabled is set to NO. Since Firebase method swizzling is disabled, we manually assign the APNs token to Firebase Messaging. Our APNs registration code is: func application( _ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data ) { print("*** APNS Device Token: ", deviceToken) Messaging.messaging().apnsToken = deviceToken Messaging.messaging().subscribe(toTopic: "testing_new_events") { error in if let error = error { print("*** Failed to subscribe: \(error.localizedDescription)") } else { print("*** Subscribed to topic successfully") } } } Main Question About the 404 UNREGISTERED Response One part of this behaviour is particularly confusing to us. If Firebase returns: 404 UNREGISTERED NotRegistered for a particular FCM token, we would expect that token to be invalid and that the application should receive or generate a completely new FCM registration token. However, when we retrieve the FCM token again from the application, Firebase may return the same token value again. Our question is: If Firebase considers an FCM token unregistered and returns 404 UNREGISTERED when sending a notification, why can Messaging.messaging().token() or the token callback still return the same token again instead of generating a new token? For example: Token A stored in backend ↓ Backend sends notification ↓ FCM returns 404 UNREGISTERED ↓ App retrieves FCM token again ↓ Firebase returns Token A again We would like to understand whether this is expected behaviour. Specifically: Does UNREGISTERED always mean that the locally cached FCM token should immediately be replaced with a new token? If not, why can the same FCM token still be returned to the application after Firebase returns UNREGISTERED for it? Is there a delay between Firebase invalidating a registration for sending and the client generating a replacement token? Is there a recommended way to force Firebase Messaging to refresh or re-register an FCM token after receiving UNREGISTERED? Could the token be cached locally even though its server-side registration is no longer valid? Additional Questions We would also appreciate guidance on the following: Is it possible for an existing FCM token to become stale or no longer usable for notification delivery without immediately returning an UNREGISTERED error for every send attempt? Can Firebase accept a message for an existing token and return a successful response, while the notification is never delivered to the device? On iOS, could the relationship between an existing FCM token and its APNs token become invalid or stale, while the application still returns the same FCM token? Is there any APNs-side reason why an old FCM token would stop receiving notifications while a newly generated/retrieved token on the same device receives notifications successfully? What is the recommended client-side and backend-side handling after receiving a 404 UNREGISTERED response? Should we immediately remove the token from our database and wait for the application to register a new token? Our main concern is understanding why an FCM token can receive a 404 UNREGISTERED response during sending, but the application can still return the same token when we attempt to retrieve it again. Any guidance on whether this behaviour is expected, particularly regarding the interaction between FCM token registration and APNs on iOS, would be greatly appreciated.

Callkit returns error code=106. I can't find what this error code means in official documents. What is this error code? Has anybody seen this error code so far? My app is VoIP app using APNs VoIP push. Below is log example of my app. 2026/04/26 09:01:45.752 [436:103]CallManager incomingCall(::::_:completion:):228: error Error Domain=com.apple.CallKit.error.incomingcall Code=106 "(null)"

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

My app was approved and released on the App Store on Aug 19, 2026 (bundle ID br.com.stackads.app, Team ID MSGM29Z362). Push notifications do not work on the production/App Store/TestFlight build. Android via FCM works fine; only iOS production APNs fails. It has been more than 48 hours since release. I captured the raw APNs device token directly from application(_:didRegisterForRemoteNotificationsWithDeviceToken:) in a production (App Store distribution) build (aps-environment = production, verified in the built .ipa entitlements). Sending directly to APNs with a token-based .p8 auth key (Key ID VXXXXXXX, Team ID MSGM29Z362), apns-topic br.com.stackads.app, apns-push-type alert, returns: api.push.apple.com (production): HTTP 403 {"reason":"BadEnvironmentKeyInToken"} api.sandbox.push.apple.com (sandbox): HTTP 400 {"reason":"BadDeviceToken"} The provider (JWT) authentication succeeds (I get a device-token error, not an auth error), so the key is valid. The App ID has the Push Notifications capability enabled. The token is freshly registered (confirmed identical between the didRegister callback and getAPNSToken). Why does the production APNs endpoint reject a valid production device token for this App ID with BadEnvironmentKeyInToken? Is there something pending in the production APNs provisioning for a newly released App ID?

Hello guys, We have updated our app icon, and it is correctly reflected in our app build and assets. However, the push notification icon is still displaying the old version for some users. ✅ We have verified that: All icon assets in Assets.xcassets match the new icon. The app icon has been updated in Info.plist. The app has been resubmitted and approved on the App Store. ❌ However, some users still see the old notification icon, even after reinstalling the app. Restarting the device does not always resolve the issue. Could you provide insights into how iOS caches notification icons and how we can force a refresh for all users?

Summary: After converting our Apple Developer account from Individual → Organization, our app stopped receiving APNs device tokens. application(:didRegisterForRemoteNotificationsWithDeviceToken:) is never called, and application(:didFailToRegisterForRemoteNotificationsWithError:) is also never called — no token, no error. This affects all new device‑token registrations app‑wide; device tokens issued before the conversion still work and continue to deliver pushes. Environment Membership status: Active Device: iPhone 15 Pro, iOS [26.6] Reproduced on both development (sandbox) builds installed via Xcode/CLI and TestFlight builds. What works Existing device tokens (created before ~Aug 1) still deliver pushes normally (server reports delivered 1/1 via our .p8 token‑based auth). So the send path and APNs auth key are fine. UNUserNotificationCenter authorization succeeds — authorizationStatus == .authorized. UIApplication.shared.isRegisteredForRemoteNotifications == true. What doesn't work We call UIApplication.shared.registerForRemoteNotifications() on the main thread after authorization is granted, but neither delegate callback ever fires — no token, no error — on any new install/launch. Timeline / trigger Everything worked before the Individual→Organization conversion. Since the conversion, no new APNs device token has been issued for the app at all. Server‑side we can confirm the most recent device token was created 2026‑08‑01, and none since, despite many fresh installs/launches across multiple users. Pre‑conversion tokens still function. What we've already tried / ruled out App ID has Push Notifications capability enabled; regenerated provisioning profiles. Generated a new APNs Auth Key (.p8) (sends already work, so this was expected not to matter). Fixed the Xcode signing team (it briefly showed "Unknown Name (TEAMID)" right after conversion; resolved by signing into the correct org account — Team now resolves correctly). Device reboot, network settings reset, app delete/reinstall, latest iOS. Confirmed delegate is wired (@UIApplicationDelegateAdaptor) — the same code issued tokens fine before the conversion. Thanks in advance!